tools: x86_energy_perf_policy: Fix "uninitialized variable" warnings at -O2

x86_energy_perf_policy first uses __get_cpuid() to check the maximum
CPUID level and exits if it is too low.  It then assumes that later
calls will succeed (which I think is architecturally guaranteed).  It
also assumes that CPUID works at all (which is not guaranteed on
x86_32).

If optimisations are enabled, gcc warns about potentially
uninitialized variables.  Fix this by adding an exit-on-error after
every call to __get_cpuid() instead of just checking the maximum
level.

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic bugfix/x86
Gbp-Pq: Name tools-x86_energy_perf_policy-fix-uninitialized-varia.patch

usbip: Fix misuse of strncpy()

gcc 8 reports:

usbip_device_driver.c: In function ‘read_usb_vudc_device’:
usbip_device_driver.c:106:2: error: ‘strncpy’ specified bound 256 equals destination size [-Werror=stringop-truncation]
  strncpy(dev->path, path, SYSFS_PATH_MAX);
  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
usbip_device_driver.c:125:2: error: ‘strncpy’ specified bound 32 equals destination size [-Werror=stringop-truncation]
  strncpy(dev->busid, name, SYSFS_BUS_ID_SIZE);
  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

I'm not convinced it makes sense to truncate the copied strings here,
but since we're already doing so let's ensure they're still null-
terminated.  We can't easily use strlcpy() here, so use snprintf().

usbip_common.c has the same problem.

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name usbip-fix-misuse-of-strncpy.patch

tools/lib/api/fs/fs.c: Fix misuse of strncpy()

gcc 8 reports:

In function 'fs__env_override',
    inlined from 'fs__get_mountpoint' at fs/fs.c:228:6:
fs/fs.c:222:2: error: 'strncpy' specified bound 4096 equals destination size [-Werror=stringop-truncation]
  strncpy(fs->path, override_path, sizeof(fs->path));
  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

I'm not convinced it makes sense to truncate the copied string here,
but since we're already doing so let's ensure it's still null-
terminated.  Use strlcpy() instead.

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name tools-lib-api-fs-fs.c-fix-misuse-of-strncpy.patch

cpupower: Fix checks for CPU existence

Calls to cpufreq_cpu_exists(cpu) were converted to
cpupower_is_cpu_online(cpu) when libcpupower was introduced and the
former function was deleted.  However, cpupower_is_cpu_online() does
not distinguish physically absent and offline CPUs, and does not set
errno.

cpufreq-set has already been fixed (commit c25badc9ceb6).

In cpufreq-bench, which prints an error message for offline CPUs,
properly distinguish and report the zero and negative cases.

Fixes: ac5a181d065d ("cpupower: Add cpuidle parts into library")
Fixes: 53d1cd6b125f ("cpupowerutils: bench - Fix cpu online check")
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
[carnil: Update/Refresh patch for 4.14.17: The issue with the
incorrect check has been fixed with upstream commit 53d1cd6b125f.
Keep in the patch the distinction and report for the zero and
negative cases.]

Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name cpupower-fix-checks-for-cpu-existence.patch

libcpupower: Hide private function

cpupower_read_sysfs() (previously known as sysfs_read_file()) is an
internal function in libcpupower and should not be exported when
libcpupower is a shared library.  Change its visibility to "hidden".

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name libcpupower-hide-private-function.patch

cpupower: Bump soname version

Several functions in the libcpupower API are renamed or removed in
Linux 4.7.  This is an backward-incompatible ABI change, so the
library soname should change from libcpupower.so.0 to
libcpupower.so.1.

Fixes: ac5a181d065d ("cpupower: Add cpuidle parts into library")
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name cpupower-bump-soname-version.patch

tools/build: Remove bpf() run-time check at build time

It is not correct to test that a syscall works on the build system's
kernel.  We might be building on an earlier kernel version or with
security restrictions that block bpf().

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name tools-build-remove-bpf-run-time-check-at-build-time.patch

Revert "perf build: Fix libunwind feature detection on 32-bit x86"

This reverts commit 05b41775e2edd69a83f592e3534930c934d4038e.
It broke feature detection that was working just fine for us.

Gbp-Pq: Topic bugfix/x86
Gbp-Pq: Name revert-perf-build-fix-libunwind-feature-detection-on.patch

tools/lib/traceevent: Use LDFLAGS

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name tools-lib-traceevent-use-ldflags.patch

tools/perf: Remove shebang lines from perf scripts

perf scripts need to be invoked through perf, not directly through
perl (or other language interpreter).  So including shebang lines in
them is useless and possibly misleading.

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name tools-perf-remove-shebangs.patch

perf tools: Use $KBUILD_BUILD_TIMESTAMP as man page date

This allows man pages to be built reproducibly.

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name tools-perf-man-date.patch

kbuild: Fix recordmcount dependency for OOT modules

We never rebuild anything in-tree when building an out-of-tree
modules, so external modules should not depend on the recordmcount
sources.

Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name kbuild-fix-recordmcount-dependency.patch

usbip: Document TCP wrappers

Add references to TCP wrappers configuration in the manual page.

Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name usbip-document-tcp-wrappers.patch

module: Disable matching missing version CRC

This partly reverts commit cd3caefb4663e3811d37cc2afad3cce642d60061.
We want to fail closed if a symbol version CRC is missing, as the
alternative may allow subverting module signing.

Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name module-disable-matching-missing-version-crc.patch

PCI: Set pci=nobios by default

CONFIG_PCI_GOBIOS results in physical addresses 640KB-1MB being mapped
W+X, which is undesirable for security reasons and will result in a
warning at boot now that we enable CONFIG_DEBUG_WX.

This can be overridden using the kernel parameter "pci=nobios", but we
want to disable W+X by default.  Disable PCI BIOS probing by default;
it can still be enabled using "pci=bios".

Gbp-Pq: Topic debian
Gbp-Pq: Name i386-686-pae-pci-set-pci-nobios-by-default.patch

arm64: add kernel config option to lock down when in Secure Boot mode

Add a kernel configuration option to lock down the kernel, to restrict
userspace's ability to modify the running kernel when UEFI Secure Boot is
enabled. Based on the x86 patch by Matthew Garrett.

Determine the state of Secure Boot in the EFI stub and pass this to the
kernel using the FDT.

Signed-off-by: Linn Crosetto <linn@hpe.com>
[bwh: Forward-ported to 4.10: adjust context]
[Lukas Wunner: Forward-ported to 4.11: drop parts applied upstream]
[bwh: Forward-ported to 4.15 and lockdown patch set:
 - Pass result of efi_get_secureboot() in stub through to
   efi_set_secure_boot() in main kernel
 - Use lockdown API and naming]
[bwh: Forward-ported to 4.19.3: adjust context in update_fdt()]
[dannf: Moved init_lockdown() call after uefi_init(), fixing SB detection]

Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name arm64-add-kernel-config-option-to-lock-down-when.patch

mtd: Disable slram and phram when locked down

The slram and phram drivers both allow mapping regions of physical
address space such that they can then be read and written by userland
through the MTD interface.  This is probably usable to manipulate
hardware into overwriting kernel code on many systems.  Prevent that
if locked down.

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name mtd-disable-slram-and-phram-when-locked-down.patch

Enable cold boot attack mitigation

[Lukas Wunner: Forward-ported to 4.11: adjust context]

Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name enable-cold-boot-attack-mitigation.patch

efi: Lock down the kernel if booted in secure boot mode

UEFI Secure Boot provides a mechanism for ensuring that the firmware will
only load signed bootloaders and kernels.  Certain use cases may also
require that all kernel modules also be signed.  Add a configuration option
that to lock down the kernel - which includes requiring validly signed
modules - if the kernel is secure-booted.

Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
cc: linux-efi@vger.kernel.org

Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0029-efi-Lock-down-the-kernel-if-booted-in-secure-boot-mo.patch

efi: Add an EFI_SECURE_BOOT flag to indicate secure boot mode

UEFI machines can be booted in Secure Boot mode.  Add an EFI_SECURE_BOOT
flag that can be passed to efi_enabled() to find out whether secure boot is
enabled.

Move the switch-statement in x86's setup_arch() that inteprets the
secure_boot boot parameter to generic code and set the bit there.

Suggested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
cc: linux-efi@vger.kernel.org

Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0028-efi-Add-an-EFI_SECURE_BOOT-flag-to-indicate-secure-b.patch

bpf: Restrict kernel image access functions when the kernel is locked down

There are some bpf functions can be used to read kernel memory:
bpf_probe_read, bpf_probe_write_user and bpf_trace_printk.  These allow
private keys in kernel memory (e.g. the hibernation image signing key) to
be read by an eBPF program and kernel memory to be altered without
restriction.

Completely prohibit the use of BPF when the kernel is locked down.

Suggested-by: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: netdev@vger.kernel.org
cc: Chun-Yi Lee <jlee@suse.com>
cc: Alexei Starovoitov <alexei.starovoitov@gmail.com>
[bwh: Adjust context to apply after commit dcab51f19b29
 "bpf: Expose check_uarg_tail_zero()"]

Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0027-bpf-Restrict-kernel-image-access-functions-when-the-.patch

Lock down kprobes

Disallow the creation of kprobes when the kernel is locked down by
preventing their registration.  This prevents kprobes from being used to
access kernel memory, either to make modifications or to steal crypto data.

Reported-by: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0026-Lock-down-kprobes.patch

Lock down /proc/kcore

Disallow access to /proc/kcore when the kernel is locked down to prevent
access to cryptographic data.

Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: James Morris <james.l.morris@oracle.com>
Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0025-Lock-down-proc-kcore.patch

debugfs: Disallow use of debugfs files when the kernel is locked down

Disallow opening of debugfs files when the kernel is locked down as various
drivers give raw access to hardware through debugfs.

Accesses to tracefs should use /sys/kernel/tracing/ rather than
/sys/kernel/debug/tracing/.  Possibly a symlink should be emplaced.

Normal device interaction should be done through configfs or a miscdev, not
debugfs.

Note that this makes it unnecessary to specifically lock down show_dsts(),
show_devs() and show_call() in the asus-wmi driver.

Signed-off-by: David Howells <dhowells@redhat.com>
cc: Andy Shevchenko <andy.shevchenko@gmail.com>
cc: acpi4asus-user@lists.sourceforge.net
cc: platform-driver-x86@vger.kernel.org
cc: Matthew Garrett <matthew.garrett@nebula.com>
cc: Thomas Gleixner <tglx@linutronix.de>
[bwh: Forward-ported to 4.15]

Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0024-debugfs-Disallow-use-of-debugfs-files-when-the-kerne.patch

x86/mmiotrace: Lock down the testmmiotrace module

The testmmiotrace module shouldn't be permitted when the kernel is locked
down as it can be used to arbitrarily read and write MMIO space.

Suggested-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: David Howells <dhowells@redhat.com
cc: Thomas Gleixner <tglx@linutronix.de>
cc: Steven Rostedt <rostedt@goodmis.org>
cc: Ingo Molnar <mingo@kernel.org>
cc: "H. Peter Anvin" <hpa@zytor.com>
cc: x86@kernel.org

Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0023-x86-mmiotrace-Lock-down-the-testmmiotrace-module.patch

Lock down module params that specify hardware parameters (eg. ioport)

Provided an annotation for module parameters that specify hardware
parameters (such as io ports, iomem addresses, irqs, dma channels, fixed
dma buffers and other types).

Suggested-by: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
Signed-off-by: David Howells <dhowells@redhat.com>
Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0022-Lock-down-module-params-that-specify-hardware-parame.patch

Lock down TIOCSSERIAL

Lock down TIOCSSERIAL as that can be used to change the ioport and irq
settings on a serial port.  This only appears to be an issue for the serial
drivers that use the core serial code.  All other drivers seem to either
ignore attempts to change port/irq or give an error.

Reported-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Jiri Slaby <jslaby@suse.com>

Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0021-Lock-down-TIOCSSERIAL.patch

Prohibit PCMCIA CIS storage when the kernel is locked down

Prohibit replacement of the PCMCIA Card Information Structure when the
kernel is locked down.

Suggested-by: Dominik Brodowski <linux@dominikbrodowski.net>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: linux-pcmcia@lists.infradead.org

Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0020-Prohibit-PCMCIA-CIS-storage-when-the-kernel-is-locke.patch

acpi: Disable APEI error injection if the kernel is locked down

ACPI provides an error injection mechanism, EINJ, for debugging and testing
the ACPI Platform Error Interface (APEI) and other RAS features.  If
supported by the firmware, ACPI specification 5.0 and later provide for a
way to specify a physical memory address to which to inject the error.

Injecting errors through EINJ can produce errors which to the platform are
indistinguishable from real hardware errors.  This can have undesirable
side-effects, such as causing the platform to mark hardware as needing
replacement.

While it does not provide a method to load unauthenticated privileged code,
the effect of these errors may persist across reboots and affect trust in
the underlying hardware, so disable error injection through EINJ if
the kernel is locked down.

Signed-off-by: Linn Crosetto <linn@hpe.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: "Lee, Chun-Yi" <jlee@suse.com>
cc: linux-acpi@vger.kernel.org

Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0018-acpi-Disable-APEI-error-injection-if-the-kernel-is-l.patch

acpi: Disable ACPI table override if the kernel is locked down

From the kernel documentation (initrd_table_override.txt):

  If the ACPI_INITRD_TABLE_OVERRIDE compile option is true, it is possible
  to override nearly any ACPI table provided by the BIOS with an
  instrumented, modified one.

When securelevel is set, the kernel should disallow any unauthenticated
changes to kernel space.  ACPI tables contain code invoked by the kernel,
so do not allow ACPI tables to be overridden if the kernel is locked down.

Signed-off-by: Linn Crosetto <linn@hpe.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: "Lee, Chun-Yi" <jlee@suse.com>
cc: linux-acpi@vger.kernel.org

Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0017-acpi-Disable-ACPI-table-override-if-the-kernel-is-lo.patch

acpi: Ignore acpi_rsdp kernel param when the kernel has been locked down

This option allows userspace to pass the RSDP address to the kernel, which
makes it possible for a user to modify the workings of hardware .  Reject
the option when the kernel is locked down.

Signed-off-by: Josh Boyer <jwboyer@redhat.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: "Lee, Chun-Yi" <jlee@suse.com>
cc: Dave Young <dyoung@redhat.com>
cc: linux-acpi@vger.kernel.org

Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0016-acpi-Ignore-acpi_rsdp-kernel-param-when-the-kernel-h.patch

ACPI: Limit access to custom_method when the kernel is locked down

custom_method effectively allows arbitrary access to system memory, making
it possible for an attacker to circumvent restrictions on module loading.
Disable it if the kernel is locked down.

Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: "Lee, Chun-Yi" <jlee@suse.com>
cc: linux-acpi@vger.kernel.org

Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0015-ACPI-Limit-access-to-custom_method-when-the-kernel-i.patch

asus-wmi: Restrict debugfs interface when the kernel is locked down

We have no way of validating what all of the Asus WMI methods do on a given
machine - and there's a risk that some will allow hardware state to be
manipulated in such a way that arbitrary code can be executed in the
kernel, circumventing module loading restrictions.  Prevent that if the
kernel is locked down.

Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: "Lee, Chun-Yi" <jlee@suse.com>
cc: acpi4asus-user@lists.sourceforge.net
cc: platform-driver-x86@vger.kernel.org

Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0014-asus-wmi-Restrict-debugfs-interface-when-the-kernel-.patch

x86/msr: Restrict MSR access when the kernel is locked down

Writing to MSRs should not be allowed if the kernel is locked down, since
it could lead to execution of arbitrary code in kernel mode.  Based on a
patch by Kees Cook.

MSR accesses are logged for the purposes of building up a whitelist as per
Alan Cox's suggestion.

Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: "Lee, Chun-Yi" <jlee@suse.com>
cc: x86@kernel.org

Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0013-x86-msr-Restrict-MSR-access-when-the-kernel-is-locke.patch

x86: Lock down IO port access when the kernel is locked down

IO port access would permit users to gain access to PCI configuration
registers, which in turn (on a lot of hardware) give access to MMIO
register space. This would potentially permit root to trigger arbitrary
DMA, so lock it down by default.

This also implicitly locks down the KDADDIO, KDDELIO, KDENABIO and
KDDISABIO console ioctls.

Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: "Lee, Chun-Yi" <jlee@suse.com>
cc: x86@kernel.org

Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0012-x86-Lock-down-IO-port-access-when-the-kernel-is-lock.patch

PCI: Lock down BAR access when the kernel is locked down

Any hardware that can potentially generate DMA has to be locked down in
order to avoid it being possible for an attacker to modify kernel code,
allowing them to circumvent disabled module loading or module signing.
Default to paranoid - in future we can potentially relax this for
sufficiently IOMMU-isolated devices.

Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: "Lee, Chun-Yi" <jlee@suse.com>
cc: linux-pci@vger.kernel.org

Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0011-PCI-Lock-down-BAR-access-when-the-kernel-is-locked-d.patch

uswsusp: Disable when the kernel is locked down

uswsusp allows a user process to dump and then restore kernel state, which
makes it possible to modify the running kernel.  Disable this if the kernel
is locked down.

Signed-off-by: Matthew Garrett <mjg59@srcf.ucam.org>
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: "Lee, Chun-Yi" <jlee@suse.com>
Reviewed-by: James Morris <james.l.morris@oracle.com>
cc: linux-pm@vger.kernel.org

Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0010-uswsusp-Disable-when-the-kernel-is-locked-down.patch

hibernate: Disable when the kernel is locked down

There is currently no way to verify the resume image when returning
from hibernate.  This might compromise the signed modules trust model,
so until we can work with signed hibernate images we disable it when the
kernel is locked down.

Signed-off-by: Josh Boyer <jwboyer@fedoraproject.org>
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: "Lee, Chun-Yi" <jlee@suse.com>
cc: linux-pm@vger.kernel.org

Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0009-hibernate-Disable-when-the-kernel-is-locked-down.patch

kexec_file: Restrict at runtime if the kernel is locked down

When KEXEC_VERIFY_SIG is not enabled, kernel should not load images through
kexec_file systemcall if the kernel is locked down unless IMA can be used
to validate the image.

This code was showed in Matthew's patch but not in git:
https://lkml.org/lkml/2015/3/13/778

Cc: Matthew Garrett <mjg59@srcf.ucam.org>
Signed-off-by: Chun-Yi Lee <jlee@suse.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: James Morris <james.l.morris@oracle.com>
cc: kexec@lists.infradead.org

Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0008-kexec_file-Restrict-at-runtime-if-the-kernel-is-lock.patch

Copy secure_boot flag in boot params across kexec reboot

Kexec reboot in case secure boot being enabled does not keep the secure
boot mode in new kernel, so later one can load unsigned kernel via legacy
kexec_load.  In this state, the system is missing the protections provided
by secure boot.

Adding a patch to fix this by retain the secure_boot flag in original
kernel.

secure_boot flag in boot_params is set in EFI stub, but kexec bypasses the
stub.  Fixing this issue by copying secure_boot flag across kexec reboot.

Signed-off-by: Dave Young <dyoung@redhat.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: "Lee, Chun-Yi" <jlee@suse.com>
cc: kexec@lists.infradead.org

Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0007-Copy-secure_boot-flag-in-boot-params-across-kexec-re.patch

kexec: Disable at runtime if the kernel is locked down

kexec permits the loading and execution of arbitrary code in ring 0, which
is something that lock-down is meant to prevent. It makes sense to disable
kexec in this situation.

This does not affect kexec_file_load() which can check for a signature on the
image to be booted.

Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: Dave Young <dyoung@redhat.com>
Reviewed-by: "Lee, Chun-Yi" <jlee@suse.com>
Reviewed-by: James Morris <james.l.morris@oracle.com>
cc: kexec@lists.infradead.org
[bwh: Adjust context to apply after commit a210fd32a46b
 "kexec: add call to LSM hook in original kexec_load syscall"]

Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0006-kexec-Disable-at-runtime-if-the-kernel-is-locked-dow.patch

Restrict /dev/{mem,kmem,port} when the kernel is locked down

Allowing users to read and write to core kernel memory makes it possible
for the kernel to be subverted, avoiding module loading restrictions, and
also to steal cryptographic information.

Disallow /dev/mem and /dev/kmem from being opened this when the kernel has
been locked down to prevent this.

Also disallow /dev/port from being opened to prevent raw ioport access and
thus DMA from being used to accomplish the same thing.

Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: "Lee, Chun-Yi" <jlee@suse.com>
Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0005-Restrict-dev-mem-kmem-port-when-the-kernel-is-locked.patch

Enforce module signatures if the kernel is locked down

If the kernel is locked down, require that all modules have valid
signatures that we can verify or that IMA can validate the file.

Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: "Lee, Chun-Yi" <jlee@suse.com>
Reviewed-by: James Morris <james.l.morris@oracle.com>
[bwh: Adjust context to apply after commits 2c8fd268f418
 "module: Do not access sig_enforce directly" and 5fdc7db6448a
 "module: setup load info before module_sig_check()"]

Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0004-Enforce-module-signatures-if-the-kernel-is-locked-do.patch

ima: require secure_boot rules in lockdown mode

Require the "secure_boot" rules, whether or not it is specified
on the boot command line, for both the builtin and custom policies
in secure boot lockdown mode.

Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
Signed-off-by: David Howells <dhowells@redhat.com>
[bwh: Adjust context to apply after commits 6f0911a666d1
 "ima: fix updating the ima_appraise flag" and ef96837b0de4
 "ima: add build time policy"]

Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0003-ima-require-secure_boot-rules-in-lockdown-mode.patch

Add a SysRq option to lift kernel lockdown

Make an option to provide a sysrq key that will lift the kernel lockdown,
thereby allowing the running kernel image to be accessed and modified.

On x86 this is triggered with SysRq+x, but this key may not be available on
all arches, so it is set by setting LOCKDOWN_LIFT_KEY in asm/setup.h.
Since this macro must be defined in an arch to be able to use this facility
for that arch, the Kconfig option is restricted to arches that support it.

Signed-off-by: Kyle McMartin <kyle@redhat.com>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: x86@kernel.org
[bwh: Forward-ported to 4.15]

Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0002-Add-a-SysRq-option-to-lift-kernel-lockdown.patch

Add the ability to lock down access to the running kernel image

Provide a single call to allow kernel code to determine whether the system
should be locked down, thereby disallowing various accesses that might
allow the running kernel image to be changed including the loading of
modules that aren't validly signed with a key we recognise, fiddling with
MSR registers and disallowing hibernation,

Signed-off-by: David Howells <dhowells@redhat.com>
Acked-by: James Morris <james.l.morris@oracle.com>
Gbp-Pq: Topic features/all/lockdown
Gbp-Pq: Name 0001-Add-the-ability-to-lock-down-access-to-the-running-k.patch

Btrfs: fix corruption reading shared and compressed extents after hole punching

In the past we had data corruption when reading compressed extents that
are shared within the same file and they are consecutive, this got fixed
by commit 005efedf2c7d0 ("Btrfs: fix read corruption of compressed and
shared extents") and by commit 808f80b46790f ("Btrfs: update fix for read
corruption of compressed and shared extents"). However there was a case
that was missing in those fixes, which is when the shared and compressed
extents are referenced with a non-zero offset. The following shell script
creates a reproducer for this issue:

  #!/bin/bash

  mkfs.btrfs -f /dev/sdc &> /dev/null
  mount -o compress /dev/sdc /mnt/sdc

  # Create a file with 3 consecutive compressed extents, each has an
  # uncompressed size of 128Kb and a compressed size of 4Kb.
  for ((i = 1; i <= 3; i++)); do
      head -c 4096 /dev/zero
      for ((j = 1; j <= 31; j++)); do
          head -c 4096 /dev/zero | tr '\0' "\377"
      done
  done > /mnt/sdc/foobar
  sync

  echo "Digest after file creation:   $(md5sum /mnt/sdc/foobar)"

  # Clone the first extent into offsets 128K and 256K.
  xfs_io -c "reflink /mnt/sdc/foobar 0 128K 128K" /mnt/sdc/foobar
  xfs_io -c "reflink /mnt/sdc/foobar 0 256K 128K" /mnt/sdc/foobar
  sync

  echo "Digest after cloning:         $(md5sum /mnt/sdc/foobar)"

  # Punch holes into the regions that are already full of zeroes.
  xfs_io -c "fpunch 0 4K" /mnt/sdc/foobar
  xfs_io -c "fpunch 128K 4K" /mnt/sdc/foobar
  xfs_io -c "fpunch 256K 4K" /mnt/sdc/foobar
  sync

  echo "Digest after hole punching:   $(md5sum /mnt/sdc/foobar)"

  echo "Dropping page cache..."
  sysctl -q vm.drop_caches=1
  echo "Digest after hole punching:   $(md5sum /mnt/sdc/foobar)"

  umount /dev/sdc

When running the script we get the following output:

  Digest after file creation:   5a0888d80d7ab1fd31c229f83a3bbcc8  /mnt/sdc/foobar
  linked 131072/131072 bytes at offset 131072
  128 KiB, 1 ops; 0.0033 sec (36.960 MiB/sec and 295.6830 ops/sec)
  linked 131072/131072 bytes at offset 262144
  128 KiB, 1 ops; 0.0015 sec (78.567 MiB/sec and 628.5355 ops/sec)
  Digest after cloning:         5a0888d80d7ab1fd31c229f83a3bbcc8  /mnt/sdc/foobar
  Digest after hole punching:   5a0888d80d7ab1fd31c229f83a3bbcc8  /mnt/sdc/foobar
  Dropping page cache...
  Digest after hole punching:   fba694ae8664ed0c2e9ff8937e7f1484  /mnt/sdc/foobar

This happens because after reading all the pages of the extent in the
range from 128K to 256K for example, we read the hole at offset 256K
and then when reading the page at offset 260K we don't submit the
existing bio, which is responsible for filling all the page in the
range 128K to 256K only, therefore adding the pages from range 260K
to 384K to the existing bio and submitting it after iterating over the
entire range. Once the bio completes, the uncompressed data fills only
the pages in the range 128K to 256K because there's no more data read
from disk, leaving the pages in the range 260K to 384K unfilled. It is
just a slightly different variant of what was solved by commit
005efedf2c7d0 ("Btrfs: fix read corruption of compressed and shared
extents").

Fix this by forcing a bio submit, during readpages(), whenever we find a
compressed extent map for a page that is different from the extent map
for the previous page or has a different starting offset (in case it's
the same compressed extent), instead of the extent map's original start
offset.

A test case for fstests follows soon.

Reported-by: Zygo Blaxell <ce3g8jdj@umail.furryterror.org>
Tested-by: Zygo Blaxell <ce3g8jdj@umail.furryterror.org>
Cc: stable@vger.kernel.org # 4.3+
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name btrfs-fix-corruption-reading-shared-and-compressed-e.patch

mt76: Use the correct hweight8() function

mt76_init_stream_cap() and mt76_get_txpower() call __sw_hweight8()
directly, but that's only defined if CONFIG_GENERIC_HWEIGHT is
enabled.  The function that works on all architectures is hweight8().

Fixes: 551e1ef4d291 ("mt76: add mt76_init_stream_cap routine")
Fixes: 9313faacbb4e ("mt76: move mt76x02_get_txpower to mt76 core")
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
[bwh: For 4.19, drop change in mt76_get_txpower()]

Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name mt76-use-the-correct-hweight8-function.patch

Revert "objtool: Fix CONFIG_STACK_VALIDATION=y warning for out-of-tree modules"

This reverts commit 9f0c18aec620bc9d82268b3cb937568dd07b43ff.  This
check doesn't make sense for OOT modules as they should always use
a pre-built objtool.

Gbp-Pq: Topic debian
Gbp-Pq: Name revert-objtool-fix-config_stack_validation-y-warning.patch

Kbuild.include: addtree: Remove quotes before matching path

systemtap currently fails to build modules when the kernel source and
object trees are separate.

systemtap adds something like -I"/usr/share/systemtap/runtime" to
EXTRA_CFLAGS, and addtree should not adjust this as it's specifying an
absolute directory.  But since make has no understanding of shell
quoting, it does anyway.

For a long time this didn't matter, because addtree would still emit
the original -I option after the adjusted one.  However, commit
db547ef19064 ("Kbuild: don't add obj tree in additional includes")
changed it to remove the original -I option.

Remove quotes (both double and single) before matching against the
excluded patterns.

References: https://bugs.debian.org/856474
Reported-by: Jack Henschel <jackdev@mailbox.org>
Reported-by: Ritesh Raj Sarraf <rrs@debian.org>
Fixes: db547ef19064 ("Kbuild: don't add obj tree in additional includes")
Cc: stable@vger.kernel.org # 4.8+
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name kbuild-include-addtree-remove-quotes-before-matching-path.patch

Partially revert "usb: Kconfig: using select for USB_COMMON dependency"

This reverts commit cb9c1cfc86926d0e86d19c8e34f6c23458cd3478 for
USB_LED_TRIG.  This config symbol has bool type and enables extra code
in usb_common itself, not a separate driver.  Enabling it should not
force usb_common to be built-in!

Fixes: cb9c1cfc8692 ("usb: Kconfig: using select for USB_COMMON dependency")
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name partially-revert-usb-kconfig-using-select-for-usb_co.patch

fs: Add MODULE_SOFTDEP declarations for hard-coded crypto drivers

This helps initramfs builders and other tools to find the full
dependencies of a module.

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
[Lukas Wunner: Forward-ported to 4.11: drop parts applied upstream]

Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name fs-add-module_softdep-declarations-for-hard-coded-cr.patch

phy/marvell: disable 4-port phys

The Marvell PHY was originally disabled because it can cause networking
failures on some systems. According to Lennert Buytenhek this is because some
of the variants added did not share the same register layout. Since the known
cases are all 4-ports disable those variants (indicated by a 4 in the
penultimate position of the model name) until they can be audited for
correctness.

[bwh: Also #if-out the init functions for these PHYs to avoid
 compiler warnings]

Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name disable-some-marvell-phys.patch

kbuild: Use -nostdinc in compile tests

gcc 4.8 and later include <stdc-predef.h> by default.  In some
versions of eglibc that includes <bits/predefs.h>, but that may be
missing when building with a biarch compiler.  Also <stdc-predef.h>
itself could be missing as we are only trying to build a kernel, not
userland.

The -nostdinc option disables this, though it isn't explicitly
documented.  This option is already used when actually building
the kernel, but not by cc-option and other tests.  This can result
in silently miscompiling the kernel.

References: https://bugs.debian.org/717557
References: https://bugs.debian.org/726861
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic bugfix/all
Gbp-Pq: Name kbuild-use-nostdinc-in-compile-tests.patch

arm64: dts: allwinner: a64: Add Pine64-LTS device tree file

The Pine64-LTS is a variant of the Pine64 board, from the software
visible side resembling a SoPine module on a baseboard, though the
board has the SoC and DRAM integrated on one PCB.
Due to this it basically shares the DT with the SoPine baseboard, which
we mimic in our DT by inclucing the boardboard .dts into the new file,
just overwriting the model name.
Having a separate .dts for this seems useful, since we don't know yet if
there are subtle differences between the two. Also the SoC on the LTS
board is technically an "R18" instead of the original "A64", although as
far as we know this is just a relabelled version of the original SoC.

Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Gbp-Pq: Topic features/arm64
Gbp-Pq: Name arm64-dts-allwinner-a64-Add-Pine64-LTS-device-tree-f.patch

x86/boot: Clear RSDP address in boot_params for broken loaders

Gunnar Krueger reported a systemd-boot failure and bisected it down to:

  e6e094e053af75 ("x86/acpi, x86/boot: Take RSDP address from boot params if available")

In case a broken boot loader doesn't clear its 'struct boot_params', clear
rsdp_addr in sanitize_boot_params().

Reported-by: Gunnar Krueger <taijian@posteo.de>
Tested-by: Gunnar Krueger <taijian@posteo.de>
Signed-off-by: Juergen Gross <jgross@suse.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: bp@alien8.de
Cc: sstabellini@kernel.org
Fixes: e6e094e053af75 ("x86/acpi, x86/boot: Take RSDP address from boot params if available")
Link: http://lkml.kernel.org/r/20181203103811.17056-1-jgross@suse.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Gbp-Pq: Topic features/x86
Gbp-Pq: Name x86-boot-Clear-RSDP-address-in-boot_params-for-broke.patch

x86/acpi, x86/boot: Take RSDP address from boot params if available

In case the RSDP address in struct boot_params is specified don't try
to find the table by searching, but take the address directly as set
by the boot loader.

Suggested-by: "H. Peter Anvin" <hpa@zytor.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: boris.ostrovsky@oracle.com
Cc: bp@alien8.de
Cc: daniel.kiper@oracle.com
Cc: sstabellini@kernel.org
Cc: xen-devel@lists.xenproject.org
Link: http://lkml.kernel.org/r/20181120072529.5489-3-jgross@suse.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Gbp-Pq: Topic features/x86
Gbp-Pq: Name x86-acpi-x86-boot-Take-RSDP-address-from-boot-params.patch

x86/boot: Mostly revert commit ae7e1238e68f2a ("Add ACPI RSDP address to setup_header")

Peter Anvin pointed out that commit:

  ae7e1238e68f2a ("x86/boot: Add ACPI RSDP address to setup_header")

should be reverted as setup_header should only contain items set by the
legacy BIOS.

So revert said commit. Instead of fully reverting the dependent commit
of:

  e7b66d16fe4172 ("x86/acpi, x86/boot: Take RSDP address for boot params if available")

just remove the setup_header reference in order to replace it by
a boot_params in a followup patch.

Suggested-by: "H. Peter Anvin" <hpa@zytor.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: boris.ostrovsky@oracle.com
Cc: bp@alien8.de
Cc: daniel.kiper@oracle.com
Cc: sstabellini@kernel.org
Cc: xen-devel@lists.xenproject.org
Link: http://lkml.kernel.org/r/20181120072529.5489-2-jgross@suse.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Gbp-Pq: Topic features/x86
Gbp-Pq: Name x86-boot-Mostly-revert-commit-ae7e1238e68f2a-Add-ACP.patch

x86/acpi, x86/boot: Take RSDP address for boot params if available

In case the RSDP address in struct boot_params is specified don't try
to find the table by searching, but take the address directly as set
by the boot loader.

Signed-off-by: Juergen Gross <jgross@suse.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Baoquan He <bhe@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Jia Zhang <qianyue.zj@alibaba-inc.com>
Cc: Len Brown <len.brown@intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Pavel Tatashin <pasha.tatashin@oracle.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: boris.ostrovsky@oracle.com
Cc: linux-kernel@vger.kernel.org
Cc: linux-pm@vger.kernel.org
Cc: xen-devel@lists.xenproject.org
Link: http://lkml.kernel.org/r/20181010061456.22238-4-jgross@suse.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Gbp-Pq: Topic features/x86
Gbp-Pq: Name x86-acpi-x86-boot-Take-RSDP-address-for-boot-params-.patch

x86/boot: Add ACPI RSDP address to setup_header

Xen PVH guests receive the address of the RSDP table from Xen. In order
to support booting a Xen PVH guest via Grub2 using the standard x86
boot entry we need a way for Grub2 to pass the RSDP address to the
kernel.

For this purpose expand the struct setup_header to hold the physical
address of the RSDP address. Being zero means it isn't specified and
has to be located the legacy way (searching through low memory or
EBDA).

While documenting the new setup_header layout and protocol version
2.14 add the missing documentation of protocol version 2.13.

There are Grub2 versions in several distros with a downstream patch
violating the boot protocol by writing past the end of setup_header.
This requires another update of the boot protocol to enable the kernel
to distinguish between a specified RSDP address and one filled with
garbage by such a broken Grub2.

From protocol 2.14 on Grub2 will write the version it is supporting
(but never a higher value than found to be supported by the kernel)
ored with 0x8000 to the version field of setup_header. This enables
the kernel to know up to which field Grub2 has written information
to. All fields after that are supposed to be clobbered.

Signed-off-by: Juergen Gross <jgross@suse.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: boris.ostrovsky@oracle.com
Cc: bp@alien8.de
Cc: corbet@lwn.net
Cc: linux-doc@vger.kernel.org
Cc: xen-devel@lists.xenproject.org
Link: http://lkml.kernel.org/r/20181010061456.22238-3-jgross@suse.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Gbp-Pq: Topic features/x86
Gbp-Pq: Name x86-boot-Add-ACPI-RSDP-address-to-setup_header.patch

x86: Make x32 syscall support conditional on a kernel parameter

Enabling x32 in the standard amd64 kernel would increase its attack
surface while provide no benefit to the vast majority of its users.
No-one seems interested in regularly checking for vulnerabilities
specific to x32 (at least no-one with a white hat).

Still, adding another flavour just to turn on x32 seems wasteful.  And
the only differences on syscall entry are a few instructions that mask
out the x32 flag and compare the syscall number.

Use a static key to control whether x32 syscalls are really enabled, a
Kconfig parameter to set its default value and a kernel parameter
"syscall.x32" to change it at boot time.

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic features/x86
Gbp-Pq: Name x86-make-x32-syscall-support-conditional.patch

x86: memtest: WARN if bad RAM found

Since this is not a particularly thorough test, if we find any bad
bits of RAM then there is a fair chance that there are other bad bits
we fail to detect.

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic features/x86
Gbp-Pq: Name x86-memtest-WARN-if-bad-RAM-found.patch

MIPS: Loongson 3: Add Loongson LS3A RS780E 1-way machine definition

Add a Loongson LS3A RS780E 1-way machine definition, which only differs
from other Loongson 3 based machines by the UART base clock speed.

Signed-off-by: Aurelien Jarno <aurelien@aurel32.net>
[bwh: Forward-ported to 4.2]

Gbp-Pq: Topic features/mips
Gbp-Pq: Name MIPS-Loongson-3-Add-Loongson-LS3A-RS780E-1-way-machi.patch

MIPS: increase MAX_PHYSMEM_BITS on Loongson 3 only

Commit c4617318 broke Loongson-2 support and maybe even more by increasing
the value of MAX_PHYSMEM_BITS. At it is currently only needed on
Loongson-3, define it conditionally.

Note: this should be replace by upstream fix when available.

Gbp-Pq: Topic features/mips
Gbp-Pq: Name MIPS-increase-MAX-PHYSMEM-BITS-on-Loongson-3-only.patch

MIPS: Loongson: Introduce and use loongson_llsc_mb()

On the Loongson-2G/2H/3A/3B there is a hardware flaw that ll/sc and
lld/scd is very weak ordering. We should add sync instructions "before
each ll/lld" and "at the branch-target between ll/sc" to workaround.
Otherwise, this flaw will cause deadlock occasionally (e.g. when doing
heavy load test with LTP).

Below is the explaination of CPU designer:

"For Loongson 3 family, when a memory access instruction (load, store,
or prefetch)'s executing occurs between the execution of LL and SC, the
success or failure of SC is not predictable. Although programmer would
not insert memory access instructions between LL and SC, the memory
instructions before LL in program-order, may dynamically executed
between the execution of LL/SC, so a memory fence (SYNC) is needed
before LL/LLD to avoid this situation.

Since Loongson-3A R2 (3A2000), we have improved our hardware design to
handle this case. But we later deduce a rarely circumstance that some
speculatively executed memory instructions due to branch misprediction
between LL/SC still fall into the above case, so a memory fence (SYNC)
at branch-target (if its target is not between LL/SC) is needed for
Loongson 3A1000, 3B1500, 3A2000 and 3A3000.

Our processor is continually evolving and we aim to to remove all these
workaround-SYNCs around LL/SC for new-come processor."

Here is an example:

Both cpu1 and cpu2 simutaneously run atomic_add by 1 on same atomic var,
this bug cause both 'sc' run by two cpus (in atomic_add) succeed at same
time('sc' return 1), and the variable is only *added by 1*, sometimes,
which is wrong and unacceptable(it should be added by 2).

Why disable fix-loongson3-llsc in compiler?
Because compiler fix will cause problems in kernel's __ex_table section.

This patch fix all the cases in kernel, but:

+. the fix at the end of futex_atomic_cmpxchg_inatomic is for branch-target
of 'bne', there other cases which smp_mb__before_llsc() and smp_llsc_mb() fix
the ll and branch-target coincidently such as atomic_sub_if_positive/
cmpxchg/xchg, just like this one.

+. Loongson 3 does support CONFIG_EDAC_ATOMIC_SCRUB, so no need to touch
edac.h

+. local_ops and cmpxchg_local should not be affected by this bug since
only the owner can write.

+. mips_atomic_set for syscall.c is deprecated and rarely used, just let
it go

Signed-off-by: Huacai Chen <chenhc@lemote.com>
Signed-off-by: Huang Pei <huangpei@loongson.cn>
[paul.burton@mips.com:
  - Simplify the addition of -mno-fix-loongson3-llsc to cflags, and add
    a comment describing why it's there.
  - Make loongson_llsc_mb() a no-op when
    CONFIG_CPU_LOONGSON3_WORKAROUNDS=n, rather than a compiler memory
    barrier.
  - Add a comment describing the bug & how loongson_llsc_mb() helps
    in asm/barrier.h.]
Signed-off-by: Paul Burton <paul.burton@mips.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: ambrosehua@gmail.com
Cc: Steven J . Hill <Steven.Hill@cavium.com>
Cc: linux-mips@linux-mips.org
Cc: Fuxin Zhang <zhangfx@lemote.com>
Cc: Zhangjin Wu <wuzhangjin@gmail.com>
Cc: Li Xuefeng <lixuefeng@loongson.cn>
Cc: Xu Chenghua <xuchenghua@loongson.cn>
Gbp-Pq: Topic bugfix/mips
Gbp-Pq: Name MIPS-Loongson-Introduce-and-use-loongson_llsc_mb.patch

arm64: dts: allwinner: a64: Enable A64 timer workaround

As instability in the architectural timer has been observed on multiple
devices using this SoC, inluding the Pine64 and the Orange Pi Win,
enable the workaround in the SoC's device tree.

Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
Signed-off-by: Samuel Holland <samuel@sholland.org>
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Gbp-Pq: Topic bugfix/arm64
Gbp-Pq: Name arm64-dts-allwinner-a64-Enable-A64-timer-workaround.patch

ARM: dts: sun8i-h3: add sy8106a to orange pi plus

The Orange Pi Plus board lacks voltage scaling capabilities in its
current form. This results in random freezes during boot when cpufreq is
enabled, probably due to wrong voltages.

This patch (more or less copy/paste from 06139c) does the following
things on this board:
- enable r_i2c
- add sy8106a to the r_i2c bus
- have the sy8106a regulate VDD of cpu

Since the Orange Pi Plus has the same PMU setup as the Orange Pi PC, I
simply took min/max/fixed/ramp from the latter DTS. In that file the
origin of the values are described by the following comment:

  "The datasheet uses 1.1V as the minimum value of VDD-CPUX,
  however both the Armbian DVFS table and the official one
  have operating points with voltage under 1.1V, and both
  DVFS table are known to work properly at the lowest
  operating point.
  Use 1.0V as the minimum voltage instead."

I have tested this on patch two Orange Pi Plus boards, by running a
kernel with this patch and do intermettent runs of cpuburn while
monitoring voltage, frequency and temperature. The board runs stable
across its operatiing points while showing a reasonable (< 40C)
temperature. My Orange Pi PC, when put to the same test, yields similar
stable results.

Signed-off-by: Jorik Jonker <jorik@kippendief.biz>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Gbp-Pq: Topic bugfix/arm
Gbp-Pq: Name ARM-dts-sun8i-h3-add-sy8106a-to-orange-pi-plus.patch

x86/kvmclock: set offset for kvm unstable clock

VMs may show incorrect uptime and dmesg printk offsets on hypervisors with
unstable clock. The problem is produced when VM is rebooted without exiting
from qemu.

The fix is to calculate clock offset not only for stable clock but for
unstable clock as well, and use kvm_sched_clock_read() which substracts
the offset for both clocks.

This is safe, because pvclock_clocksource_read() does the right thing and
makes sure that clock always goes forward, so once offset is calculated
with unstable clock, we won't get new reads that are smaller than offset,
and thus won't get negative results.

Thank you Jon DeVree for helping to reproduce this issue.

Fixes: 857baa87b642 ("sched/clock: Enable sched clock early")
Reported-by: Dominique Martinet <asmadeus@codewreck.org>
Signed-off-by: Pavel Tatashin <pasha.tatashin@soleen.com>
[carnil: Backport to 4.19 for context changes]

Gbp-Pq: Topic bugfix/x86
Gbp-Pq: Name x86-kvmclock-set-offset-for-kvm-unstable-clock.patch

Build with -ffreestanding on m68k to avoid risky optimizations involving libc

Gbp-Pq: Topic bugfix/m68k
Gbp-Pq: Name m68k-build-with-ffreestanding.patch

powerpc: Fix -mcpu= options for SPE-only compiler

GCC for Debian's "powerpcspe" architecture only supports 32-bit
SPE targets, and using -mcpu=powerpc or -mcpu=powerpc64 is a fatal
error.

* Change the test for a biarch compiler to pass both the -m32 and -m64
  options, so that it doesn't catch 32-bit-only compilers
* Add an ifdef CONFIG_PPC64 around the 64-bit CPU option definitions

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic bugfix/powerpc
Gbp-Pq: Name powerpc-fix-mcpu-options-for-spe-only-compiler.patch

x86-32: Disable 3D-Now in generic config

We want the 686 flavour to run on Geode LX and similar AMD family 5
CPUs as well as family 6 and higher CPUs.  This used to work with
CONFIG_M686=y.  However commit 25d76ac88821 "x86/Kconfig: Explicitly
enumerate i686-class CPUs in Kconfig" in Linux 4.16 has made the
kernel require family 6 or higher.

It looks like a sensible choice would be to enable CONFIG_MGEODE_LX
and CONFIG_X86_GENERIC (for more generic optimisations), but this
currently enables CONFIG_X86_USE_3D_NOW which will cause the kernel to
crash on CPUs without the AMD-specific 3D-Now instructions.

Make CONFIG_X86_USE_3DNOW depend on CONFIG_X86_GENERIC being disabled.

Gbp-Pq: Topic bugfix/x86
Gbp-Pq: Name x86-32-disable-3dnow-in-generic-config.patch

arm64/acpi: Add fixup for HPE m400 quirks

Adds a new ACPI init routine acpi_fixup_m400_quirks that adds
a work-around for HPE ProLiant m400 APEI firmware problems.

The work-around disables APEI when CONFIG_ACPI_APEI is set and
m400 firmware is detected.  Without this fixup m400 systems
experience errors like these on startup:

  [Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 2
  [Hardware Error]: event severity: fatal
  [Hardware Error]:  Error 0, type: fatal
  [Hardware Error]:   section_type: memory error
  [Hardware Error]:   error_status: 0x0000000000001300
  [Hardware Error]:   error_type: 10, invalid address
  Kernel panic - not syncing: Fatal hardware error!

Signed-off-by: Geoff Levand <geoff@infradead.org>
[bwh: Adjust context to apply to Linux 4.19]

Gbp-Pq: Topic bugfix/arm64
Gbp-Pq: Name arm64-acpi-Add-fixup-for-HPE-m400-quirks.patch

powerpc/boot: Fix missing crc32poly.h when building with KERNEL_XZ

After commit faa16bc404d7 ("lib: Use existing define with
polynomial") the lib/xz/xz_crc32.c includes a header from include/linux
directory thus any other user of this code should define proper include
path.

This fixes the build error on powerpc with CONFIG_KERNEL_XZ:

    In file included from ../arch/powerpc/boot/../../../lib/decompress_unxz.c:233:0,
                     from ../arch/powerpc/boot/decompress.c:42:
    ../arch/powerpc/boot/../../../lib/xz/xz_crc32.c:18:29: fatal error: linux/crc32poly.h: No such file or directory

Reported-by: Michal Kubecek <mkubecek@suse.cz>
Fixes: faa16bc404d7 ("lib: Use existing define with polynomial")
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Reported-by: kbuild test robot <lkp@intel.com>
Reported-by: Meelis Roos <mroos@linux.ee>
Tested-by: Michal Kubecek <mkubecek@suse.cz>
Gbp-Pq: Topic bugfix/powerpc
Gbp-Pq: Name powerpc-boot-fix-missing-crc32poly.h-when-building-with-kernel_xz.patch

ARM: mm: Export __sync_icache_dcache() for xen-privcmd

The xen-privcmd driver, which can be modular, calls set_pte_at()
which in turn may call __sync_icache_dcache().

The call to __sync_icache_dcache() may be optimised out because it is
conditional on !pte_special(), and xen-privcmd calls pte_mkspecial().
However, in a non-LPAE configuration there is no "special" bit and the
call is really unconditional.

Fixes: 3ad0876554ca ("xen/privcmd: add IOCTL_PRIVCMD_MMAP_RESOURCE")
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic bugfix/arm
Gbp-Pq: Name arm-mm-export-__sync_icache_dcache-for-xen-privcmd.patch

powerpc/lib/Makefile: Don't pull in quad.o for 32-bit kernels

The functions exported by quad.o are only used when guarded by
__powerpc64__ and so are unused on 32-bit kernels. Moreover, their
implementations make use of instructions which will cause an illegal
instruction error on 32-bit processors, and are not accepted by the
assembler for SPE processors.

Fixes: 31bfdb036f12 ("powerpc: Use instruction emulation infrastructure to handle alignment faults")
Signed-off-by: James Clarke <jrtc27@jrtc27.com>
Gbp-Pq: Topic bugfix/powerpc
Gbp-Pq: Name powerpc-lib-makefile-don-t-pull-in-quad.o-for-32-bit.patch

powerpc/lib/sstep: Fix building for powerpcspe

On powerpcspe, ptesync is not a recognised instruction and so fails to
assemble. We don't expect to have to emulate an lwsync or a ptesync on a
32-bit kernel, so just ifdef them out, and catch any unexpected barrier
types.

Fixes: 3cdfcbfd32b9 ("powerpc: Change analyse_instr so it doesn't modify *regs")
Signed-off-by: James Clarke <jrtc27@jrtc27.com>
Gbp-Pq: Topic bugfix/powerpc
Gbp-Pq: Name powerpc-lib-sstep-fix-building-for-powerpcspe.patch

sh: Do not use hyphen in exported variable names

arch/sh/Makefile defines and exports ld-bfd to be used by
arch/sh/boot/Makefile and arch/sh/boot/compressed/Makefile.  Similarly
arch/sh/boot/Makefile defines and exports suffix-y to be used by
arch/sh/boot/compressed/Makefile.  However some shells, including
dash, will not pass through environment variables whose name includes
a hyphen.  Usually GNU make does not use a shell to recurse, but if
e.g. $(srctree) contains '~' it will use a shell here.

Rename these variables to ld_bfd and suffix_y.

References: https://buildd.debian.org/status/fetch.php?pkg=linux&arch=sh4&ver=4.13%7Erc5-1%7Eexp1&stamp=1502943967&raw=0
Fixes: ef9b542fce00 ("sh: bzip2/lzma uImage support.")
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic bugfix/sh
Gbp-Pq: Name sh-boot-do-not-use-hyphen-in-exported-variable-name.patch

perf tools: Fix unwind build on i386

EINVAL may not be defined when building unwind-libunwind.c with
REMOTE_UNWIND_LIBUNWIND, resulting in a compiler error in
LIBUNWIND__ARCH_REG_ID().  Its only caller, access_reg(), only checks
for a negative return value and doesn't care what it is.  So change
-EINVAL to -1.

Fixes: 52ffe0ff02fc ("Support x86(32-bit) cross platform callchain unwind.")
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic bugfix/x86
Gbp-Pq: Name perf-tools-fix-unwind-build-on-i386.patch

platform/x86: ideapad-laptop: Add several models to no_hw_rfkill

Some Lenovo ideapad models do not have hardware rfkill switches, but
trying to read the rfkill switches through the ideapad-laptop module.
It caused to always reported blocking breaking wifi.

Fix it by adding those models to no_hw_rfkill_list.

Signed-off-by: Yang Jiaxun <yjx@flygoat.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Gbp-Pq: Topic bugfix/x86
Gbp-Pq: Name platform-x86-ideapad-laptop-add-several-models-to-no.patch

platform/x86: ideapad-laptop: Add IdeaPad V510-15IKB to no_hw_rfkill

Like other Lenovo models the IdeaPad V510-15IKB does not have an hw
rfkill switch. This results in hard-blocked radios after boot, resulting
in always blocked radios rendering them unusable.

Add the IdeaPad V510-15IKB to the no_hw_rfkill DMI list and allows using
the built-in radios.

Signed-off-by: Sven Eckelmann <sven@narfation.org>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Gbp-Pq: Topic bugfix/x86
Gbp-Pq: Name platform-x86-ideapad-laptop-add-ideapad-v510-15ikb-t.patch

platform/x86: ideapad-laptop: Add Y720-15IKBN to no_hw_rfkill

Lenovo Legion Y720-15IKBN is yet another Lenovo model that does not
have an hw rfkill switch, resulting in wifi always reported as hard
blocked.

Add the model to the list of models without rfkill switch.

Signed-off-by: Olle Liljenzin <olle@liljenzin.se>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Gbp-Pq: Topic bugfix/x86
Gbp-Pq: Name platform-x86-ideapad-laptop-add-y720-15ikbn-to-no_hw.patch

platform/x86: ideapad-laptop: Add Y520-15IKBN to no_hw_rfkill

Lenovo Legion Y520-15IKBN is yet another Lenovo model that does not
have an hw rfkill switch, resulting in wifi always reported as hard
blocked.

Add the model to the list of models without rfkill switch.

Signed-off-by: Olle Liljenzin <olle@liljenzin.se>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Gbp-Pq: Topic bugfix/x86
Gbp-Pq: Name platform-x86-ideapad-laptop-add-y520-15ikbn-to-no_hw.patch

platform/x86: ideapad-laptop: Add IdeaPad V310-15ISK to no_hw_rfkill

Like other Lenovo models the IdeaPad V310-15ISK does not have an hw
rfkill switch. This results in hard-blocked radios after boot, resulting
in always blocked radios rendering them unusable.

Add the IdeaPad V310-15ISK to the no_hw_rfkill DMI list and allows using
the built-in radios.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Gbp-Pq: Topic bugfix/x86
Gbp-Pq: Name platform-x86-ideapad-laptop-add-ideapad-v310-15isk-t.patch

platform/x86: ideapad-laptop: Add IdeaPad 310-15IKB to no_hw_rfkill

Like other Lenovo models the IdeaPad 310-15IKB does not have an hw rfkill
switch. This results in hard-blocked radios after boot, resulting in
always blocked radios rendering them unusable.

Add the IdeaPad 310-15IKB to the no_hw_rfkill DMI list and allows using
the built-in radios.

Signed-off-by: Sven Rebhan <Sven.Rebhan@googlemail.com>
[andy: massaged commit message]
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Gbp-Pq: Topic bugfix/x86
Gbp-Pq: Name platform-x86-ideapad-laptop-add-ideapad-310-15ikb-to.patch

arm64: dts: rockchip: correct voltage selector on Firefly-RK3399

Without this patch the Firefly-RK3399 board boot process hangs after these
lines:

   fan53555-regulator 0-0040: FAN53555 Option[8] Rev[1] Detected!
   fan53555-reg: supplied by vcc_sys
   vcc1v8_s3: supplied by vcc_1v8

Blacklisting driver fan53555 allows booting.

The device tree uses a value of fcs,suspend-voltage-selector different to
any other board.

Changing this setting to the usual value is sufficient to enable booting
and also matches the value used in the vendor kernel.

Fixes: 171582e00db1 ("arm64: dts: rockchip: add support for firefly-rk3399 board")
Cc: stable@vger.kernel.org
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Gbp-Pq: Topic bugfix/arm64
Gbp-Pq: Name dts-rockchip-correct-voltage-selector-firefly-RK3399.patch

ARM: dts: kirkwood: Fix SATA pinmux-ing for TS419

The old board code for the TS419 assigns MPP pins 15 and 16 as SATA
activity signals (and none as SATA presence signals).  Currently the
device tree assigns the SoC's default pinmux groups for SATA, which
conflict with the second Ethernet port.

Reported-by: gmbh@gazeta.pl
Tested-by: gmbh@gazeta.pl
References: https://bugs.debian.org/855017
Cc: stable@vger.kernel.org # 3.15+
Fixes: 934b524b3f49 ("ARM: Kirkwood: Add DT description of QNAP 419")
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic bugfix/arm
Gbp-Pq: Name arm-dts-kirkwood-fix-sata-pinmux-ing-for-ts419.patch

btrfs: warn about RAID5/6 being experimental at mount time

Too many people come complaining about losing their data -- and indeed,
there's no warning outside a wiki and the mailing list tribal knowledge.
Message severity chosen for consistency with XFS -- "alert" makes dmesg
produce nice red background which should get the point across.

Signed-off-by: Adam Borowski <kilobyte@angband.pl>
[bwh: Also add_taint() so this is flagged in bug reports]

Gbp-Pq: Topic debian
Gbp-Pq: Name btrfs-warn-about-raid5-6-being-experimental-at-mount.patch

fanotify: Taint on use of FANOTIFY_ACCESS_PERMISSIONS

Various free and proprietary AV products use this feature and users
apparently want it.  But punting access checks to userland seems like
an easy way to deadlock the system, and there will be nothing we can
do about that.  So warn and taint the kernel if this feature is
actually used.

Gbp-Pq: Topic debian
Gbp-Pq: Name fanotify-taint-on-use-of-fanotify_access_permissions.patch

fjes: Disable auto-loading

fjes matches a generic ACPI device ID, and relies on its probe
function to distinguish whether that really corresponds to a supported
device.  Very few system will need the driver and it wastes memory on
all the other systems where the same device ID appears, so disable
auto-loading.

Gbp-Pq: Topic debian
Gbp-Pq: Name fjes-disable-autoload.patch

viafb: Autoload on OLPC XO 1.5 only

It appears that viafb won't work automatically on all the boards for
which it has a PCI device ID match.  Currently, it is blacklisted by
udev along with most other framebuffer drivers, so this doesn't matter
much.

However, this driver is required for console support on the XO 1.5.
We need to allow it to be autoloaded on this model only, and then
un-blacklist it in udev.

Gbp-Pq: Topic bugfix/x86
Gbp-Pq: Name viafb-autoload-on-olpc-xo1.5-only.patch

snd-pcsp: Disable autoload

There are two drivers claiming the platform:pcspkr device:
- pcspkr creates an input(!) device that can only beep
- snd-pcsp creates an equivalent input device plus a PCM device that can
  play barely recognisable renditions of sampled sound

snd-pcsp is blacklisted by the alsa-base package, but not everyone
installs that.  On PCs where no sound is wanted at all, both drivers
will still be loaded and one or other will complain that it couldn't
claim the relevant I/O range.

In case anyone finds snd-pcsp useful, we continue to build it.  But
remove the alias, to ensure it's not loaded where it's not wanted.

Gbp-Pq: Topic debian
Gbp-Pq: Name snd-pcsp-disable-autoload.patch

cdc_ncm,cdc_mbim: Use NCM by default

Devices that support both NCM and MBIM modes should be kept in NCM
mode unless there is userland support for MBIM.

Set the default value of cdc_ncm.prefer_mbim to false and leave it to
userland (modem-manager) to override this with a modprobe.conf file
once it's ready to speak MBIM.

Gbp-Pq: Topic debian
Gbp-Pq: Name cdc_ncm-cdc_mbim-use-ncm-by-default.patch

security,perf: Allow further restriction of perf_event_open

When kernel.perf_event_open is set to 3 (or greater), disallow all
access to performance events by users without CAP_SYS_ADMIN.
Add a Kconfig symbol CONFIG_SECURITY_PERF_EVENTS_RESTRICT that
makes this value the default.

This is based on a similar feature in grsecurity
(CONFIG_GRKERNSEC_PERF_HARDEN).  This version doesn't include making
the variable read-only.  It also allows enabling further restriction
at run-time regardless of whether the default is changed.

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic features/all
Gbp-Pq: Name security-perf-allow-further-restriction-of-perf_event_open.patch

add sysctl to disallow unprivileged CLONE_NEWUSER by default

add sysctl to disallow unprivileged CLONE_NEWUSER by default

This is a short-term patch.  Unprivileged use of CLONE_NEWUSER
is certainly an intended feature of user namespaces.  However
for at least saucy we want to make sure that, if any security
issues are found, we have a fail-safe.

Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
[bwh: Remove unneeded binary sysctl bits]

Gbp-Pq: Topic debian
Gbp-Pq: Name add-sysctl-to-disallow-unprivileged-CLONE_NEWUSER-by-default.patch

yama: Disable by default

Gbp-Pq: Topic debian
Gbp-Pq: Name yama-disable-by-default.patch

sched: Do not enable autogrouping by default

We want to provide the option of autogrouping but without enabling
it by default yet.

Gbp-Pq: Topic debian
Gbp-Pq: Name sched-autogroup-disabled.patch

fs: Enable link security restrictions by default

This reverts commit 561ec64ae67ef25cac8d72bb9c4bfc955edfd415
('VFS: don't do protected {sym,hard}links by default').

Gbp-Pq: Topic debian
Gbp-Pq: Name fs-enable-link-security-restrictions-by-default.patch

dccp: Disable auto-loading as mitigation against local exploits

We can mitigate the effect of vulnerabilities in obscure protocols by
preventing unprivileged users from loading the modules, so that they
are only exploitable on systems where the administrator has chosen to
load the protocol.

The 'dccp' protocol is not actively maintained or widely used.
Therefore disable auto-loading.

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic debian
Gbp-Pq: Name dccp-disable-auto-loading-as-mitigation-against-local-exploits.patch

decnet: Disable auto-loading as mitigation against local exploits

Recent review has revealed several bugs in obscure protocol
implementations that can be exploited by local users for denial of
service or privilege escalation.  We can mitigate the effect of any
remaining vulnerabilities in such protocols by preventing unprivileged
users from loading the modules, so that they are only exploitable on
systems where the administrator has chosen to load the protocol.

The 'decnet' protocol is unmaintained and of mostly historical
interest, and the user-space support package 'dnet-common' loads the
module explicitly.  Therefore disable auto-loading.

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic debian
Gbp-Pq: Name decnet-Disable-auto-loading-as-mitigation-against-lo.patch

rds: Disable auto-loading as mitigation against local exploits

Recent review has revealed several bugs in obscure protocol
implementations that can be exploited by local users for denial of
service or privilege escalation.  We can mitigate the effect of any
remaining vulnerabilities in such protocols by preventing unprivileged
users from loading the modules, so that they are only exploitable on
systems where the administrator has chosen to load the protocol.

The 'rds' protocol is one such protocol that has been found to be
vulnerable, and which was not present in the 'lenny' kernel.
Therefore disable auto-loading.

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Gbp-Pq: Topic debian
Gbp-Pq: Name rds-Disable-auto-loading-as-mitigation-against-local.patch